home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re ODF's Color Model.1 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  6.1 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ODF's Color Model
  2. Sent:        5/23/96 10:00 PM
  3. Received:    5/24/96 8:49 AM
  4. From:        Damon Cokenias, cokenias@mtn-palace.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8.  
  9. >   The inlines FW_RGB_R, ...G, and ...B clearly show an intent to encode
  10. >the RGB values as 8-bit (uchar) intensities.  Unfortunately, the setting inline
  11. >function FW_SetRGB uses the value-setting macro FW_RGB with short values
  12. >for r, g, and b.  If one looks at the Set function's interface, which is
  13. >reflected upward to _all_ color classes and their interfaces, one is lead to
  14. >believe that 16-bit (i.e., Mac-like) color values are supported.  This is not
  15. >the case, unfortunately.  Although the parameters are shorts, only values in
  16. >the range 0..255 will work _correctly_.  All others _will_ result in incorrect
  17. >colors being encoded in the ulong fRGB.
  18.  
  19. I agree, the API should use 8-bit values instead of 16.  I also found this
  20. misleading when I first used ODF.
  21.  
  22. >   I consider the basic ODF color representation (a single unsigned long
  23. >_encodoing_  of an 8-bit rgb color model) to be inadequate.  For example, SGI
  24. >is now shipping a (medical imaging) system using triple 12-bit DAC's, requiring
  25. >at least 36-bit representations of colors.  Then there is the Pantone Corp.'s
  26. >Hexachrome (tm) hi-fi color system, with 6 color intensities.  How do we encode
  27. >this system in 32 bits?  Hmmm?  5-bit intensities?
  28.  
  29. Obviously, you do not encode 36 bit values using only 32 bits.  You use a
  30. custom solution, perhaps taking advantage of platform-specific APIs and
  31. data structures.
  32.  
  33. >If ODF intends to provide a platform-independent imaging model, it cannot and
  34. >must not rely upon a lowest-common-denominator approach, it must support a
  35. >model that is powerful enough to support the most powerful existing models and
  36. >allow for future growth in imaging technology.  I believe that this requires,
  37. >among other things, a 48-bit or greater color model.
  38.  
  39. PostScript and OpenGL are full-featured, platform-independent imaging
  40. systems.  ODF does not try to provide this level of abstraction from the
  41. underlying graphics system.  Instead we put a thin, platform neutral
  42. wrapper around the platform-specific imaging routines.  Just enough to save
  43. most users from the horrors of QuickDraw/GDI, not so much that performance
  44. is seriously damaged.
  45.  
  46. It is a fact that display hardware used on current PCs and Macs (and quite
  47. possibly million dollar SGI medical systems) can only display 24 bits of
  48. color.  Even on the best monitor, of those 16 million colors, your eye will
  49. only be able to distinguish between perhaps a few hundred thousand.  For
  50. screen display ODF's color model is more than enough.
  51.  
  52. ODF's color model is not good enough if your part is designed to manipulate
  53. 2400 dpi/30 bit color scans.  But chances are, if you are writing code to
  54. handle images with such precision you know how to do it better than we can.
  55.  
  56. >   While I'm in rant mode, I'd like to take a shot at the available ODF
  57. >documentation.  Sure, ODF is a work in progress, but is that any excuse not to
  58. >write meaningful comments in the code?  Remember, ODF source code must be
  59. >read and understood by (hopefully tens of) thousands of programmers.  Getting
  60. >all these people enthusiastic about ODF requires that we not have to work _too_
  61. >hard to understand it.  The ODF Class Reference (ODFCR) is only about 2/3
  62. >written, and even that is (necessarily, I realize) not fully up to date.  How
  63. >am I supposed grok the essence (let alone the fullness) of anything in the
  64. >framework layer when there is _no_ data in the ODFCR (at least the useable one
  65. >in Quickview form) on the Framework layer?  I frankly don't have the spare time
  66. >to waste thrashing thru the engineering notes, the development notes and other
  67. >random possible sources to try to find prose explanations for why some things
  68. >are done the way they are.  If such explanations exist except inside some
  69. >already overworked Apple programmer's head.
  70.  
  71. I think that if you do spend the time to read the engineering notes
  72. specific to your problem you will find your time is not wasted.  Quite
  73. possibly by doing so you will be able to provide us with constructive
  74. criticism so the Framework layer documentation is as good as it can be
  75. before it gets locked into a more formal format (like a printed book, for
  76. instance).
  77.  
  78. As a member of the QA team, my eyes bleed from the amount of ODF
  79. documentation I have reviewed.  We make every effort to ensure it is as
  80. legible, accurate and approachable as possible.  Naturally, we are few and
  81. our developers are many.  We (the QA team) cannot possibly read piece of
  82. documentation with the pure objectivity of a newcomer.
  83.  
  84. Please help us help you.
  85.  
  86. >  ODF has a lot of potential, but it is a tool and the usability of any complex
  87. >tool is highly dependant on its documentation.  Consider this a plea for some
  88. >additional efforts in that area.
  89.  
  90. If you have the OpenDoc DR5 CD (from WWDC) or have visited our web page
  91. <http://www.devtools.apple.com/odf/download.html> you have ODF Release 1.
  92. You will see there are two applications on the CD, one for installing ODF
  93. with almost no user interaction and another that automates the CodeWarrior
  94. build process.
  95.  
  96. You no longer need to use MPW to build your CodeWarrior parts and ODFRC,
  97. the cross-platform resource compiler is now available as a CodeWarrior
  98. plugin.  With each release you will see us improve the usability and
  99. approachability of ODF.  These recent steps were partly the result of
  100. developer feedback we've received from earlier releases.
  101.  
  102. Please provide us with as much focused, constructive criticism as possible
  103. and we will endeavor to meet your needs.
  104.  
  105. >Martin, Bill & the Sigma 4 gang
  106.  
  107. -Damon Cokenias
  108. A Quality ODF Team Member
  109.  
  110.  
  111. +-----------------------------------------------------------------------+
  112. |   /\    Damon Cokenias                                                |
  113. |  /^^\   cokenias@mtn-palace.com                                       |
  114. | /____\  Visit the Mountain Palace at http://www.netgate.net/~cokenias |
  115. +-----------------------------------------------------------------------+
  116.  
  117.